Drivers are programs that can extend an operating system to enable support for devices that the operating system does not natively support. Drivers are tightly integrated with the operating system upon which they execute. For example, drivers typically share the same address space as the operating system and use the same primitives as the operating system. Each driver therefore, like any other part of an operating system, can affect an entire computing device and user experience. For example, when a driver crashes, all the other programs executing on the host computing device will also typically crash.
Driver programmers are confronted with myriad issues that make it difficult to create drivers that execute reliably and performantly. For instance, operating systems commonly require drivers to support very specific rules, protocols, data formats, and application programming interfaces (“APIs”). Driver programmers must, therefore, understand these complex requirements in detail. Inexperienced driver programmers might view these requirements as annoyances and obstacles to work around and, consequently, write drivers that circumvent some of the requirements, which may result in drivers that are unreliable and potentially non-performant.
Reliable and performant drivers are also difficult to write because they must often deal with many events that can happen very fast or very slowly at times, and in an unpredictable order. Moreover, drivers must process many events immediately and process some events in stages. As a result, drivers can miss events in some cases. In addition, an operating system and application programs can call into a driver at any time. Due to this complexity, it is not uncommon for drivers to include programming errors that cause race conditions, whereby a driver depends on the sequence or timing of processes or threads for it to operate properly.
Because driver development is extremely difficult, some programmers will reuse program code by copying program source code from another driver. This practice might also result in an unreliable and non-performant driver. For instance, if a programmer does not understand the copied driver source code, the resulting driver can end up containing unneeded, non-executed, or rarely executed code that serves no useful purpose and thereby reduces the performance of the driver. Code developed using these types of practices may also increase the probability of the code failing.
It is with respect to these and other technical challenges that the disclosure made herein is presented.